home *** CD-ROM | disk | FTP | other *** search
/ Aminet 49 / Aminet 49 (2002)(GTI - Schatztruhe)[!][Jun 2002].iso / Aminet / dev / cross / cmdline.readme < prev    next >
Encoding:
Text File  |  2002-03-23  |  7.2 KB  |  218 lines
  1. Short:    Commandline utilities for C64 crossdevelopment
  2. Author:   loorni@student.oulu.fi Amiga port by (Ventzislav Tzvetkov)
  3. Uploader: drHirudo@Amigascne.org (Ventzislav Tzvetkov)
  4. Type:     dev/cross
  5.  
  6.  
  7. Commandline utilities for C64 crossdevelopment
  8. ----------------------------------------------
  9.  
  10. Utilities written by Lasse Öörni (loorni@student.oulu.fi)
  11.  
  12. CovertBitOps C64 page: http://covertbitops.cjb.net
  13.  
  14. As these are text-only programs, they should be fairly portable.
  15. Borland's free C compiler has been used by default to compile these
  16. but any C compiler should do.
  17.  
  18.  
  19. PRG2BIN.EXE
  20. -----------
  21.  
  22. Usage: PRG2BIN infile outfile [bytes to strip, default 2]
  23.  
  24. This program removes a certain amount of bytes from the beginning of the
  25. input file and saves it as the output file. With the default setting
  26. of 2 bytes, it converts PRG files into raw binary files.
  27.  
  28.  
  29. PRG2D64.EXE
  30. -----------
  31. Usage: PRG2D64 diskimage c64filename dosfilename
  32.  
  33. This program reads the PC filesystem file indicated by dos filename, and
  34. writes it to the D64 diskimage given, with the desired c64 filename. Use
  35. the underscore _ to represent blanks in the c64 filename.
  36.  
  37.  
  38. D642PRG.EXE
  39. -----------
  40. Usage: D642PRG diskimage c64filename dosfilename
  41.  
  42. This program does the opposite, it extracts the c64 file from the diskimage
  43. and writes it to a PC filesystem file indicated by dos filename. Like above,
  44. Use the underscore _ to represent blanks in the c64 filename.
  45.  
  46.  
  47. D64REN.EXE
  48. ----------
  49. Usage: D64REN diskimage oldname newname
  50.  
  51. This program renames one file on a D64 diskimage. Use the underscore _
  52. represent blanks in the filenames.
  53.  
  54.  
  55. MAKEDISK.EXE
  56. ------------
  57. Usage: MAKEDISK diskimage commandfile [diskname] [interleave]
  58.  
  59. This program creates a D64 diskimage from scratch, reading dos filename
  60. c64 filename pairs from the commandfile and writing those files on the image.
  61. A disk name and the sector interleave (10 is the default) can be optionally
  62. given. Fiddling with the interleave is nice when trying to find the optimal
  63. loading speed (minimal sector read waiting time) for an IRQ-loader. Use the
  64. underscore _ to represent blanks in the c64 filenames.
  65.  
  66. Example of a commandfile: (from the BOFH game)
  67. bofh.pak BOFH_V1.0
  68. instr.pak BOFH_MANUAL
  69. hiscore.bin BOFH_HISCORE
  70.  
  71. So, bofh.pak is written on the image as BOFH V1.0, instr.pak as BOFH MANUAL
  72. and so on.
  73.  
  74.  
  75. C64PACK.EXE
  76. -----------
  77. Usage: C64PACK infile outfile [switches]
  78. Switches:
  79.        /r Raw input and output file (no start address)
  80.  
  81. Packs a C64 file using my quite ineffective string-pack algorithm. (the only
  82. good side is that the depacker is short). The input and output file can even
  83. be same, because input file is first totally stored in memory.
  84.  
  85. If the /r switch is given, the input file is assumed to be a raw binary file
  86. without the 2-byte starting address (like in PRG files) and the output file
  87. will be raw binary also. Otherwise, the output file contains the same start
  88. address as the input file.
  89.  
  90.  
  91. C64UNP.EXE
  92. ----------
  93. Usage: C64UNP infile outfile
  94.  
  95. This program reverses the compression done by above program. NOTE: this
  96. program can only handle files with startaddress! All in all, I see no good
  97. reason to use this program at all :)
  98.  
  99.  
  100. PACKPRG.EXE
  101. -----------
  102. Usage: PACKPRG infile outfile execution address in hexadecimal
  103.  
  104. This program packs an executable PRG file with the above mentioned
  105. algorithm and adds a depacker, making the file startable with a RUN
  106. command. The depacker will start the executable with a JMP to the
  107. execution address, with the value $37 in memory location $01 (enable
  108. Basic ROM, Kernal ROM and I/O area)
  109.  
  110. This program needs the file DEPACK.S (depacker source code in DASM
  111. source code format) in the current directory and DASM.EXE in the
  112. path, because it invokes DASM to assemble the depacker and link it
  113. with the packed executable data.
  114.  
  115.  
  116. BENTON64.EXE
  117. ------------
  118. Usage: BENTON64 infile outfile [switches]
  119. Switches:
  120.        /hXX Clip picture height to XX
  121.        /wXX Clip picture width to XX
  122.        /bXX Set background ($D021) color to XX
  123.         By default it's the most used color.
  124.        /sXX Set picture start address in hex (default a000)
  125.        /r   Raw save (no .PRG start address included)
  126.        /o   Optimal save (do not align bitmap & screen data to page boundary)
  127.        /c   Save color data before bitmap
  128.  
  129. This is Benton Invertor 64 (heh...don't ask where the name comes
  130. from :)), my C64 multicolor picture conversion program.
  131.  
  132. The input file has to be in Deluxe Paint IFF/LBM format. Switches
  133. determine what portion of the picture will be converted, and to
  134. what format.
  135.  
  136. By default a 320x200 picture would be saved like:
  137.  
  138. 2 bytes startaddress
  139. 8192 bytes of bitmap data
  140. 1024 bytes of screen memory data
  141. 1024 bytes of color memory data
  142. As you see, the bitmap/screen/color data lengths are rounded to the next
  143. page (256 bytes) boundary.
  144.  
  145. By using the /o switch it would be:
  146. 2 bytes startaddress
  147. 8000 bytes of bitmap data
  148. 1000 bytes of screen memory data
  149. 1000 bytes of color memory data
  150. (no wasted bytes)
  151.  
  152. Note that the background color isn't saved with the picture! This is a
  153. downside.
  154.  
  155.  
  156. CUTSCENE.EXE
  157. ------------
  158. Usage: CUTSCENE infile outfile [switches]
  159. Switches:
  160.        /bXX Set background ($D021) color to XX. Default 0.
  161.        /mXX Set multicolor 1 to XX.
  162.        /nXX Set multicolor 2 to XX.
  163.        /xXX Set Xsize to XX. (default 20)
  164.        /yXX Set Ysize to XX. (default 9)
  165.        /c   Don't save colormap
  166.  
  167. This is a customized conversion program for Metal Warrior cutscene pictures.
  168. It converts a LBM picture into character (not bitmap) data + screen data.
  169. The output file is always in raw binary format (no startaddress) and it's as
  170. follows:
  171.  
  172. xsize*ysize chars of screen memory data
  173. xsize*ysize chars of color memory data, if not disabled
  174. as many chars of chardata as needed
  175.  
  176. Note that screen memory char codes start from 64, because in Metal Warrior
  177. characters 0-63 were always reserved for the textscreen font. Not a really
  178. useful program...
  179.  
  180.  
  181. PIC2SPR.EXE
  182. -----------
  183. Usage: PIC2SPR infile outfile [switches]
  184. Switches:
  185.        /hXX Clip picture height to XX sprites
  186.        /wXX Clip picture width to XX sprites
  187.        /bXX Set background color to XX. Default 0.
  188.        /mXX Set sprite multicolor 1 to XX.
  189.        /nXX Set sprite multicolor 2 to XX.
  190.        /sXX Set data start address in hex (default a000)
  191.        /r   Raw save (no .PRG start address included)
  192.  
  193. This is the customized graphics conversion program for Metal Warrior 2, that
  194. uses sprites in its cutscene graphics. Basically, an IFF/LBM picture will
  195. be converted into sprites, the sprites going left-right and top-bottom in the
  196. like this: (example has 4 sprites horizontally)
  197.  
  198.   1 2 3 4
  199.   5 6 7 8
  200.  
  201. The sprites are saved in the .SPR format, which means raw sprite data with
  202. the 64th byte in each sprite defining the sprite color.
  203.  
  204.  
  205. SPRRIP.EXE
  206. ----------
  207. Usage: SPRRIP ramdumpfile banknumber outfile [spritecolor]
  208.  
  209. This program takes a 64KB dump file containing the C64 RAM, such as C64.RAM
  210. used by old versions of CCS64, and rips all 256 sprites from a certain
  211. videobank. The bank numbers are the same that are written to the low 2 bits
  212. of $dd00 (3 = $0000-$3fff, 2 = $4000-$7fff etc.). Destination file is simply
  213. the sprite file name (in the same .SPR file format as used by SPREDIT.EXE)
  214. and the optional spritecolor parameter is what to put in the 64th byte of
  215. each sprite.
  216.  
  217. This is a program I rarely use :)
  218.